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Remarks 

Claims 1-21 are pending. Claims 1, 5, 8-12, 14, 16 and 19-21 were amended 
to particularly point out and distinctly claim Applicant's invention, as is discussed below in 
coimection with the section Objections to the Claims. 

OBJECTIONS TO THE CLAIMS 

The Examiner objects to Claims 1,11 and 21 on the ground of informalities. 
The Examiner states that the term "NT" "should incorporate with its full form." 

As was suggested by the Examiner, the term "NT" has been replaced by "New 

Technology". 

Claim 1 , as amended, recites "New Technology File Structure". It is 
submitted that this recital is clear to one of ordinary skill in the art. The specification (page 1 , 
lines 17-18) defmes "NT File Structure" as being equivalent to "NTFS". It is submitted that 
"NTFS" is also clear to one of ordinary skill in the art. See, for example, attached Exhibit 1 
(page 1, first paragraph), which defines NTFS as the "New Technology" File System. See, 
also, Berghel et al.. page 1, f3 (of record). 

Claims 1 1 and 21, as both are amended, include a similar recital of "New 
Technology File Structure" as Clahn 1 . It is submitted that this recital is clear for the same 
reasons. 

Claims 5, 8-10, 12, 14, 16, 19 and 20 have been amended in a like manner. 

Since the objections to Claims 1 and 1 1 have been dealt with, it is submitted 
that any objections to Claims 2-10 and 12-20, which depend from Claims 1 and 1 1, 
respectively, have also been dealt with. 

REJECTIONS UNDER 35 U.S.C. 8 112. 112 

The Examiner rejects Claims 1-21 under 35 U.S.C. § 1 12, second paragraph, 
on the ground of being indefinite. 

The Examiner stales that the term "installer" is unclear. As to Claims 1,11 
and 2 1 , the Examiner fiirther states {emphasis added) that the term installer is unclear "as . . . 
used to install the file or the files are simply gets copied where no installer is needed. In the 
claim language it seems that the files are only copying from one location to another." 

It is respectfully stated that the Examiner has not responded to any of the 
previous remarks directed to this rejection, other than to state (Office Action, page 2) that it 
"fiirther applies to new claim 21 ." First of all, the Examiner is of the unsupported position 
that "no installer is needed". It is respectfully submitted tliat this unsupported position is not 
well taken in view of the refined recitals {emphasis added) of Claim 1 of "employing an 
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instaUer"; "writing a Primary Data Stream file to said New Technology File Structure logical 
volume from said instaUer"; and "writing said associated data to said New Technology File 
Structure logical volume as an Alternate Data Stream file from said instaUer". Hence, since 
the recited installer is employed, and since both a Primary Data Stream file and associated 
data as an Altemate Data Stream file are written to an New Technology File Structure logical 
volume fi-om the installer, it is respectfully submitted that the unsupported position that "no 
installer is needed" cannot reasonably be supported. What is the logic or evidence by which 
the Examiner holds that "no installer is needed"? 

Claim 1 1 recites (emphasis added) the '■'instaUer cooperating with said 
processor to write a Primary Data Stream file to said New Technology File Structure logical 
volume, associate data with said Primary Data Stream file, and write said associated data to 
said New Technology File Structure logical volume as an Altemate Data Stream file." For 
similar reasons as were discussed above in connection with Claim 1, it is respectfiilly 
submitted that the position that "no installer is needed" cannot reasonably be supported. The 
recited installer cooperates with the processor to write a Primary Data Stream file to the New 
Technology File Structure logical volume. The recited installer also cooperates with the 
processor to associate data with the Primary Data Stream file. The recited installer fiirther 
cooperates with the processor to write the associated data to the New Technology File 
Structure logical volume as an Altemate Data Stream file. Again, what is the logic or 
evidence by which the Examiner holds that "no installer is needed"? 

Claim 21 recites (emphasis added) '^employing an instaUer, writing a Primary 
Data Stream file to said New Technology File Stmcture logical volume of said computer- 
readable medium from said instaUer, associating data with said Primary Data Stream file; 
and writing said associated data to said New Technology File Structure logical volume of 
said computer-readable mediimi as an Altemate Data Stream file from said instaUer". For 
similar reasons as were discussed above in connection with Claim 1, it is respectfiilly 
submitted that the position that "no installer is needed" cannot reasonably be supported. 
Again, what is the logic or evidence by which the Examiner holds that "no installer is 
needed"? 

Since the Examiner has the burden of proof for any rejection, but has not 
responded to any of the previous remarks directed to this rejection, then to the extent that the 
Examiner might continue to hold that Applicant's arguments in this regard are "not 
persuasive," clarification of the Examiner's position is respectfully requested. 
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Secondly, the term "installer" is understood by those of ordinary skill in the 
art. See, for example, U.S. Patent No. 6,744,450 (Zimniewicz et al. ) (col. 6, 1. 45, reciting 
"existing installer technology") (of record). 

Again, since the Examiner has the burden of proof for any rejection, but has 
not responded to any of the previous remarks directed to this rejection, then to the extent that 
the Examiner might continue to hold that Applicant's arguifients in this regard are "not 
persuasive," clarification of the Examiner's position is respectftilly requested. 

Therefore, it is submitted that the recited installer of Claims 1,11 and 21 is 
definite and passes muster under Section 112, second paragraph. 

As to the recital "associating data" of Claims I and 2 1 , the Examiner states 

that it is "unclear as to what data is being associated with Primary Data Stream". As was 

discussed above. Claim 1 recites "associating data with said Primary Data Stream file; and 

writing said associated data to said New Technology File Structure logical volume as an 

Alternate Data Stream file from said installer." Within the context of Claim 1, it is 

respectfiilly submitted that Applicant may recite "data" as broadly as possible without 

limiting said data.. As is stated in Section 2173.04 of the Manual of Patent Examining 

Procedure (MPEP): 

Breadth of a claim is not to be equated with indefiniteness. 
In re Miller, 441 F.2d 689, 169 USPQ 597 (CCPA 1971). 
If the scope of the subject matter embraced by the claims is 
clear, and if applicants have not otherwise indicated that 
they intend the invention to be of a scope different from 
that defined in the claims, then the claims comply with 35 
U.S.C. 112, second paragraph. 

MPEP § 2173.04. Hence, it is submitted that the recital "associating data" of Claim 1 is 
definite and passes muster under Section 1 12, second paragraph. 

Claim 21 recites "associating data with said Primary Data Stream file; and 
writing said associated data to said New Technology File Structure logical volume of said 
computer-readable medium as an Alternate Data Stream file from said installer." Within the 
context of Claim 21, it is respectfiilly submitted that Applicant may recite "data" as broadly 
as possible without limiting said data. MPEP § 2173.04. Therefore, it is submitted that the 
recital "associating data" of Claim 21 is definite and passes muster under Section 112, second 
paragraph. 

To the extent that the Examiner may have any authority to the contrary, then 
citation of that authority is respectfiilly requested. Since the Examiner has the burden of 
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proof for any rejection and has not responded to any of the previous remarks directed to this 
rejection, then to the extent that the Examiner might continue to hold that Applicant's 
arguments in this regard are "not persuasive," clarification of the Examiner's position is 
respectfully requested. 

Since the rejections to Claims 1 and 1 1 have been dealt with, it is submitted 
that the rejections of Claims 2-10 and 12-20, which depend from Claims 1 and 11, 
respectively, have also been dealt with. 

REJECTIONS UNDER 35 U.S.C. S 102fa) 

The Examiner rejects Claims 1, 3-5, 8-12, 14-16 and 19-21 on the ground of 
being anticipated by "Phishing in Alternate Data Streams" ( Berghel et al.) . 

Berphel et al. discloses primary and alternate data streams (ADSs) in the New 
Technology File System (NTFS) of Microsoft. This reference also discloses that (page 1) a 
"large number of alternate data streams (ADSs) may be associated with a single primary data 
stream (PDS)", that (pages 3-4) a user renames <calc.exe> as the ADS, <d.exe>, and 
associates it with an empty text file <test.txt> by employing a command line of a DOS 
command prompt window, and that (page 6) there is "malware" that takes advantage of 
ADSs {e.g., W2k.stream). 

Claim 1 recites, inter alia, a method for secure installation and operation of 
software comprising: employing an New Technology File Structure logical volume; 
employing an installer; writing a Primary Data Stream file to the New Technology File 
Structure logical volume from the installer; associating data with the Primary Data Stream 
file; and writing the associated data to the New Technology File Structure logical volume as 
an Alternate Data Stream file from the installer. 

Claim 1 recites employing an installer, writing a Primary Data Stream file to 
an New Technology File Structure logical volume from such installer, and writing associated 
data with the Primary Data Stream file and to the New Technology File Structure logical 
volume as an Altemate Data Stream file from such installer. 

The Examiner admits (Office Action, page 8) that Berghel et al. is silent on an 
installer, but concludes (Office Action, page 8) that this feature is "deemed to be inherent". 
The Examiner states (Office Action, page 8) that Berghel et al. discloses "ADS contains 
binary executables (page 4, section Phishing and Executable Streams)," concludes (Office 
Action, page 4) that "obviously [an] installer is present to create executables (page 4, section 
Phishing and Executable Streams)," and concludes (Office Action, page 8) that the system of 
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the reference would be "inoperative if the installer is not present to provide ADS from PDS 
that includes executable file." These conclusions are respectfully traversed. 

A single prior art reference anticipates a patent claim only if it expressly or 
inherently describes each and every limitation set forth in the patent claim. Verdegaal Bros., 
Inc. V. Union Oil Co., 814 F.2d 628, 631, 2 U.S.P.Q.2d 1051, 1053 (Fed. Cir. 1987). 

For the following reasons, it is respectfully submitted that the Examiner 
improperly uses impermissible hindsight to reach the above conclusions in view of 
Applicant's refined recital in Claim 1. First of all, Berghel et al. (page 3, last line, and page 
4) makes crystal clear that: 

We now rename <calc.exe> as the ADS, <d.exe>, and as<?ociate it 
with the empty text file <test.txt> 

C:\...\test>type c:\windows\system32\calc.exe > .\test.txt:d.exe 

and execute the ADS directly 

C:\...\test>start .\test.txt:d.exe 

This has nothing to do with any installer within the context of Claim 1 as is understood by 
those of ordinary skill in the art. Here, the user is merely renaming files through a command 
line of a DOS command prompt window. This point was raised in the previous Amendment 
(pages 11-12) and it is noted that the Examiner has not addressed this point in the present 
Office Action. 

Second, the Examiner's conclusion that "obviously [an] installer is present to 
create executables (page 4, section Phishing and Executable Streams)," ignores the express 
teaching of the reference (page 3, last line, and page 4, first line) where a user renames 
<cialc.exe> as the ADS, <d.exe>, and associates it with the empty text file <test.txt> by 
employing a command line of a DOS command prompt window (C:\...\test>type 
c:\windows\system32\calc.exe > .\test.txt:d.exe). Here, there is no installer present and no 
such installer is taught, suggested or inherent. It is a well-known principle of patent law that 
an examiner cannot fragment the teachings of a prior art reference but must, instead, consider 
each reference as a whole.' In other words, the Examiner cannot excise and ignore, for 



' "The references must be considered as a whole and must suggest the desirability and thus the obviousness of 
making the combination." MPEP § 214 i (p. 2100-125). 
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example, the express teaching of the last line of page 3 and the first line of page 4 of the 
reference. 

Third, as to the Examiner's conclusion that the system of the reference would 
be "inoperative if the installer is not present to provide ADS from PDS that includes 
executable file," it is respectfiiUy submitted that this cannot be true since the reference 
expressly teaches that it renames files through a command line of a DOS command prompt 
window. Hence, the reference is operative and no installer is present, suggested or inherent. 

Fourth, Berehel et al. teaches and suggests a W2K. Stream virus . When this 

virus infects a file it replaces a host application with itself . Basically, the virus implements 

the simplest possible virus infection by overwriting the host program with its own code . A 

virus is completely different from the recited installer and does not install or upgrade files in 

a traditional sense. Instead, a virus usually overwrites existing files or exists as a parasite 

within existing files. This view is confirmed by the express teachings of Berghel et a!. , which 

states (page 6, at www.sarc.com/avcenter/venc/data/w2k.stream.html (of record as Cite No. 

B, "W2K.Stream")): 

The virus is basically a new subclass of companion viruses, a 
"stream companion" virus. When the virus infects a file it replaces 
the host application with itself. Basically the vims implements the 
simplest possible virus infection by overwriting the host program 
with its own code. 

Hence, a virus replaces a host application with itself This view is also supported by Exhibit 
4 of the Petition To Make Special Pursuant to 37 CFR 1.102(d), filed on October 21, 2004 (of 
record), which provides a definition of "virus" namely a "program that can 'infect' other 
programs by modifying them to include a, possibly evolved, copy of itself. A program that 
infects a computer by att[]aching itself to another program, and propagating itself when that 
program is executed." Furthermore, a malware virus is a "program or piece of code that is 
loaded onto your computer without your knowledge and runs against your wishes." See 
Exhibit 5 of the Petition To Make Special Pursuant to 37 CFR 1.102(d) (of record). 

In view of the above, it is respectfully submitted that the Examiner's 
conclusions regarding an inherent installer are based upon improper hindsight. 

As to the recitals of writing a Primary Data Stream file to an New Technology 
File Structure logical volume from an installer, and writing associated data with a Primary 
Data Stream file and to an New Technology File Structure logical volume as an Alternate 
Data Stream file from an installer, the Examiner relies on page 1 of the reference wherein it is 
stated that "large number of alternate data streams (ADSs) may be associated with a smgle 
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primary data stream (PDS)". This text, however, in no way teaches or suggests any installer, 
much less writing a Primary Data Stream file to an New Technology File Structure logical 
volume/rom an installer, or writing associated data with a Primary Data Stream file and to 
an New Technology File Structure logical volume as an Alternate Data Stream file from an 
installer. As was discussed above, it is submitted that the single reference deals with a DOS 
command line or a virus , neither of which teaches or suggests an installer. 

The reference does not teach or suggest the refined recital of employing an 
installer; writing a Primary Data Stream file to an New Technology File Structure logical 
volume/ro/M such installer, and writing associated data with the Primary Data Stream file to 
the New Technology File Structure logical volume as an Alternate Data Stream file from 
such installer. 

Accordingly, for the above reasons. Claim 1 patentably distinguishes over the 

reference. 

Claims 3-5 and 8-10 depend either directly or indirectly from Claim 1 and 
patentably distinguish over the reference for the same reasons. 

Furthermore, Claim 5 recites creating a Primary Data Stream directory chain; 
writing the Primary Data Stream directory chain to the New Technology File Structure 
logical volume from the installer; writing the Primary Data Stream file to the Primary Data 
Stream directory chain in the New Technology File Structure logical volume from the 
installer; associating the data with the Primary Data Stream directory chain or the Primary 
Data Stream file by creating and closing the Alternate Data Stream file; and installing the 
associated data to the New Technology File Structure logical volume as the Alternate Data 
Stream file from the installer. 

Since the reference neither teaches nor suggests the refined recital of Claim 1 , 
it clearly neither teaches nor suggests these additional limitations which further patentably 
distinguish over the reference. 

The Examiner's reliance on the command line of a DOS command prompt 
window ( Berghel et al. (page 2) ("First, open a DOS command prompt window.")) has 
nothing to do with any installer within the context of the claims and as understood by those of 
ordinary skill in the art. 

Furthermore, Claim 8 recites employing as the associated data first data; 
employing as the Alternate Data Stream file a first Alternate Data Stream file; employing 
second data; associating the second data with the Primary Data Stream file; and writing the 
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associated second data to the New Technology File Structure logical volume as a second 
Alternate Data Stream file from the installer. 

Since the reference neither teaches nor suggests the refined recital of Claim 1, 
it clearly neither teaches nor suggests these additional limitations which further patentably 
distinguish over the reference. 

Again, the Examiner's apparent reliance on the command line of a DOS 
command prompt window, and the Examiner's citation of "large number..." from page 1 of 
the reference, as both were discussed above in connection with Claim 1, have nothing to do 
with any installer within the context of the claims and as understood by those of ordinary skill 
in the art. 

Furthermore, Claim 10, which depends from Claim 1 and includes all of the 
limitations thereof, recites employing an installation file; defining in the installation file a 
Primary Data Stream directory chain, the Primary Data Stream file, the Alternate Data 
Stream file, and at least one information file; displaying the at least one information file fi-om 
the installation file; creating the Primary Data Stream directory chain in the New Technology 
File Structure logical volume; copying the Primary Data Stream file from the installation file 
to the Primary Data Stream directory chain in the New Technology File Structure logical 
volume; and copying the Alternate Data Stream file from the installation file to the Primary 
Data Stream directory chain in the New Technology File Structure logical volume. 

Since the reference neither teaches nor suggests the refined recital of Claim 1, 
its clearly neither teaches nor suggests these additional limitations which further distinguish 
over the reference. 

Again, the Examiner's reliance on the command line of a DOS command 
prompt window f Berghel et al. (pages 2-4 and 9)) has nothmg to do with any installer within 
the context of the claims and as understood by those of ordinary skill in the art. 

Claim 11 is an independent claim which recites, inter alia, a computer system 
for secure installation and operation of software comprising: a processor; a first drive adapted 
for access by the processor; a second drive adapted for access by the processor, the second 
drive including an New Technology File Structure logical volume; and an installer 
operatively associated with the first drive, the installer cooperating with the processor to write 
a Primary Data Stream file to the New Technology File Structure logical volume, associate 
data with the Primary Data Stream file, and write the associated data to the New Technology 
File Structure logical volume as an Alternate Data Stream file. 
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The Examiner admits that Berghel ct al. is silent on the recited installer. The 
Examiner states (Office Action, page 8) that this feature is "deemed to be inherent to Berghel 
system." The Examiner fiirther states (Office Action, page 8) that Berghel at al. (page 4) 
discloses "ADS contains binary executables" and that it would be "inoperative if the installer 
is not present to provide ADS from PDS that includes [an] executable file." These statements 
were respectfully traversed, above, in connection with Claim 1. Again, these statements have 
nothing to do with any installer within the context of the claims and as understood by those of 
ordinary skill in the art. The user in Berghel et al. is merely renaming files through a 
command line of a DOS command prompt window. This also does not teach or suggest an 
installer within the context of Claim 1 1. 

For reasons that were discussed above in connection with Claim 1 , a virus is 
completely different from the recited installer and does not install or upgrade files in a 
traditional sense. Instead, a virus usually overwrites existing files or exists as a parasite 
within existing files, and replaces a host application with itself Furthermore, a malware 
virus is a "program or piece of code that is loaded onto your computer without your 
knowledge and runs against your wishes." 

The reference does not teach or suggest the refined recital of a computer 
system for secure installation and operation of software comprising: an installer operatively 
associated with a first drive, such installer cooperating with a processor to write a Primary 
Data Stream file to an New Technology File Structure logical volume, associate data with 
such Primary Data Stream file, and write such associated data to such New Technology File 
Structure logical volume as an Alternate Data Stream file. 

Therefore, for the above reasons. Claim 1 1 patentably distinguishes over the 

reference. 

CMms 1 2, 14- 1 6, 1 9 and 20 depend either directly or indirectly from Claim 
1 1 and patentably distinguish over the reference for the same reasons. 

Furthermore, Claim 12 recites that the New Technology File Structure logical 
volume includes a directory chain or a system directory; and that the installer installs the 
Primary Data Stream file in the directory chain or the system directory of the New 
Technology File Structure logical volume. 

Since the reference neither teaches nor suggests the refined recital of Claim 
11 , it clearly neither teaches nor suggests these additional limitations which further 
patentably distinguish over the reference. 
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Again, the Examiner's reliance on the command line of a DOS command 
prompt window has nothing to do with any instailef within the context of the claims and as 
understood by those of ordinary skill in the art. 

Furthermore, Claim 16 recites that the installer cooperates with the processor 
to create a Primary Data Stream directory chain, to write the Primary Data Stream directory 
chain to the New Technology File Structure logical volume, to write the Primary Data Stream 
file to the Primary Data Stream directory chain in the New Technology File Structure logical 
volume, to associate the data with the Primary Data Stream directory chain or the Primary 
Data Stream file, and to install the associated data to the New Technology File Structure 
logical volume as the Alternate Data Stream file. 

Since the reference neither teaches nor suggests the refined recital of Claim 
11 , it clearly neither teaches nor suggests these additional limitations which further 
patentably distinguish over the reference. 

Again, the Examiner's reliance on the coimnand line of a DOS conunand 
prompt window has nothing to do with any installer within the context of the claims and as 
understood by those of ordinary skill in the art. 

Furthermore, Claim 20 recites that the processor includes a display; that the 
installer comprises an installation file including a Primary Data Stream directory chain, the 
Primary Data Stream file, the Alternate Data Stream file, and at least one information file; 
and that the installer cooperates with the processor to display the at least one information file 
from the installation file to the display, to create the Primary Data Stream directory chain in 
the New Technology File Structure logical volume, to copy the Primary Data Stream file 
firom the installation file to the Primary Data Stream directory chain in the New Technology 
File Structure logical volume, and to copy the Alternate Data Stream file from the installation 
file to the Primary Data Stream directory chain in the New Technology File Structure logical 
volume. 

Claim 20 further patentably distinguishes over the reference for similar 
reasons as were discussed above in connection with Claim 10. 

Claim 21 is an independent method claim which recites, inter alia, a method 
for secure installation and operation of software comprising: employing a computer-readable 
medium including an New Technology File Structure logical volume; employing an installer; 
writing a Primary Data Stream file to the New Technology File Structure logical volume of 
the computer-readable medium from the installer; associating data vwth the Primary Data 
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Stream file; and writing the associated data to the New Technology File Structure logical 
volume of the computer-readable medium as an Alternate Data Stream file fi:om the installer. 

For similar reasons as were discussed above in connection with Claim 1, the 
reference does not teach or suggest employing an installer; writing a Primary Data Stream 
file to an New Technology File Structure logical volume of a computer-readable medium 
from such installer, associating data with such Primary Data Stream file; and writing such 
associated data to such New Technology File Structure logical volume of such computer- 
readable medium as an Alternate Data Stream file from such installer. 

Therefore, for the above reasons, Claim 21 patentably distinguishes over the 

reference. 

REJECTIONS UNDER 35 U.S.C. S 103fa> 

The Examiner rejects Claims 2, 6, 7, 13, 17 and 1 8 on the ground of being 
unpatentable over Berghel et al. in view of U.S. Patent No. 6,744,450 ( Zimniewicz et al.V 

Zinmiewicz et al. discloses a system and method for a suite integration toolkit 
(SIT) allowing for the provision and display of a set of installation actions. 

Zinmiewicz et al.. which does not disclose any Primary Data Stream file or 
any Alternate Data Stream file, adds nothing to Berghel e t al. regarding writing a Primary 
Data Stream file or an Alternate Data Stream file to an New Technology File Structure 
logical volume from an installer to render Claims 1 or 1 1 unpatentable.^ 

Claims 2, 6 and 7 depend directly or indirectly from Claim 1 and patentably 
distinguish over the references for the same reasons. 

Furthermore, Claim 6 recites employing an installation file comprising the 
Primary Data Stream file, the Alternate Data Stream file, installation instructions, the Primary 
Data Stream directory chain, and an End User License Agreement 

Claim 6 depends directiy Smm Claim 5 and indirectly fi-om Claim 1 and 
includes all of the limitations of those claims. Since the references neither teach nor suggest 
the refined recital of Claim 5, they clearly neither teach nor suggest these additional 
limitations which further patentably distinguish over the references. 

Again, the Examiner's reliance on the command line of a DOS command 
prompt window ( Berghel et al. (page 2)) or the "large number..." ( Berghel et al. (page 1)) has 
nothing to do with any installer vWthin the context of the claims and as understood by those of 
ordinary skill in the art. 

^ The Examiner's comments regarding Zimniewicz et al. on page 4 of the Office Action do not pertain to 
Claims 1 or 1 1. 
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Claims 17 and 18 depend directly or indirectly from Claim 1 1 and patentably 
distinguish over the references for the same reasons. 

Furthermore, Claim 17 recites that the installer comprises an installation file 
comprising the Primary Data Stream file, the Alternate Data Stream file, installation 
instructions, a Primary Data Stream directory chain, and an End User License Agreement. 

Claim 17 further patentably distinguishes over the references for similar 
reasons as were discussed above in connection w^ith Claim 6. 

Furthermore, Claim 1 8 recites that the processor includes a display; and that 
the installer cooperates with the processor to display the installation instructions and the End 
User License Agreement on the display. 

Since the references neither teach nor suggest the refined recital of Claims 1 1 
and 17, they clearly neither teach nor suggest these additional limitations which fiuther 
patentably distinguish over the references. 

Again, the Examiner's reliance on the command line of a DOS command 
prompt window has nothing to do with any installer within the context of the claims and as 
understood by those of ordinary skill in the art. 

Reconsideration and early allowance are respectfully requested. 

Respectfiilly subrnitted, 




Kirk D. Houser 
Registration No. 37,357 

(41 2) 566-6083 Attorney for Applicant 
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NTFS 



From Wikipedia, the free encyclopedia 
(Redirected from Ntfs) 

NTFS or New Technology File System is the standard file system of Windows 
NT and its descendants Windows 2000, Windows XP and Windows Server 
2003. Windows versions 95, 98, 98SE and ME cannot natively read NTFS 
filesystems, although third-party utilities do exist for this purpose. 

NTFS replaced Microsoft's previous FAT file system, used in MS-DOS and 
early versions of Windows. NTFS has several improvements over FAT such as 
improved support for metadata and the use of advanced data structures to 
improve performance, reliability and disk space utilization plus additional 
extensions such as security access control lists and file system joumaling. Its 
main drawback is its veiy limited support by non-Microsoft OSes, since the 
exact specification is a trade secret of Microsoft. 

NTFS has five versions: vl.O (http://www.scotsnewsletter.com/07.htm), vl.l 
(http://www.pcguide.com/ref/hdd/file/ntfs/verNTFSll-c.html) and vl.2 found 
in NT 3.51 and NT 4, v3.0 found in Windows 2000 and v3.1 found in Windows 
XP and Windows Server 2003. These versions are sometimes refened to as 
v4.0, v5.0 and v5.1, after the version of Windows they ship with. Newer 
versions added extra features. For example, Windows 2000 introduced quotas. 
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Internals 

In NTFS, everything that has anything to do with a file (file name, creation date, 
access permissions and even contents) is stored as metadata. This elegant, albeit 
abstract, approach allowed easy addition of filesystem features during the 
course of Windows NTs development - an interesting example is the addition 
of fields for indexing used by the Active Directory software. File names are 
stored in Unicode (encoded as UTF-16, although limited to the Basic 
Multilingual Plane in early versions before Windows 2000). The downside of 
this approach is that corruption of a disk can be difiGcult to recover from. 

Internally, NTFS uses B+ trees to index file system data. Although complex to implement, this allows faster access times in some 
cases. A file system journal is used in order to guarantee the integrity of the file system itself (but not of each individual file). 
Systems usmg NTFS are known to have improved reliability compared to FAT file systems. 

Details on the implementation's internals are closed, so third-party vendors have a difficult time providing tools to handle NTFS. 

NTFS Partitions can be read by Linux since Version 2.2.0. Linux 2.6 contains a new driver written by Anton Altapamarkov 
:Cambndge University) and Richard Russon. It offers limited write support. At this time (Januaty 2006) files and directories can 



NTFS 


Developer 


I Microsotl 


Full Name 


1 New Technology File System 


Introduced 


1 July 1993 (Windows NT 3.1) 


Partition 
identifier 


0x07 (MBR) 
EBD0A0A2-B9E5-4433- 
87C0-68B6B72699C7 (GPT) 


Structures 


Directory 
contents 


j B+tree 


File allocation 


1 B+tree 


Bad Modes 


1 B+tree 


Limits 


Max file size 


1 I6EiB 


Max number of 
files 


1 4,294.967,295 (2^^ _ 


Max filename 


255 characters 


Max volume size 


16EiB 


Features 


Dates recorded 


Creation, modification, 
POSK change, access 


Date range 


Januaiy 1,1601 -May 28, 
60056 


Forks 


Yes 


Attributes 


Read-only, hidden, system, 
archive 


File system 
permissions 


ACLs 


Transparent 
compression 


Per-file, LZ77 (Windows NT 
3.51 onward) 


Transparent 
encryption 


Per-file, 
DESX (Windows 2000 
onward), 
Triple DBS (Windows XP 

onward), 
AES (Windows XP Service 
Pack 1, Windows 2003 

onward) j 



f ^lo". >™"0Med, and expanded with lira i(ed success. Due to the complexity of the internal 
NTFS strtictuies, both the bu,ltMn2,6.14kernel driver and the FUSE driver will stop miling to the volume when it detects too 

when m«„,tcd,^.„ri,e. Alternatively the WinlS^^^'t'^^^^^^^^ 
Mac OS X versions 1 0.3 and later offer read-only NTFS support. 
eComStation offers read-only NTFS support. 

Tlie Master File Table (MFT) essentially contains metadata about eveiy file and directory on an NTFS file system. It includes 
parameters such as location, size, and permissions. It is used to aid in minimizing disk fragmentation. 

Interoperability 

Microsoft currently provides a tool to convert the FAT32 foimat to NTFS. but not the other way around. PartitionMagic by 
NTF^prrtitbnt' "^''^ NTFSResize utility (http://mlf.linux.rulez.org/mlfi' ezaz/ntfsresize.html) are both capable of resizing 

For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore 
so do all file systems other than NTFS that are supported by cmrent versions of Windows. However, Windows NT and its 
descendants keep mtenial timestamps as GMT/UTC and make the appropriate conveisions for display purposes. Therefore, NTFS 
tmiestamps are m GMT/UTC. Tliis means that when files are copied or moved between NTFS and non-NTFS partitions, the OS 
needs to convert timestamps on the fly. But if some files are moved when summer or "daylight" local time is in effect, and odier 
files are moved whai winter or "standard" local time is in effect, there can be some ambiguities in the conversions. As a result, 
especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that 
are incorrect by one hour. Due to the differences in implementation of Daylight Savings between the Northern and Southern 
hemispheres, this can result in a potential timestamp error of up to 4 hours in any given 12 months. 

Features 

NTFS 5.0 was tiie third, version of NTFS to be introduced to the Windows world by Microsoft. It included several new features- 
quotas, sparse file support, reparse points, distributed link trackmg and the Encrypting File System (EFS). 

Ahemate data streams (ADS) 

ta^ITf^ vST^ ^'*'^^/''^ to ^ associated with more than one data stream. For example, a file such as texttxt can 
have a ADS with tiie iiame of texttxtisecrettxt (oHoim filemme. ads) that can only be accessed by knowing the ADS 
^n^tZn^iuF^W^r^T^"^^^ ^^^^"^^^ detectable in the original file's size but are 

lost when the original file (i.e text.tct) is deleted, or when the file is copied or moved to a partition that doesn't support 

^^S- e?;^' ^/ J/! !T " * ^"*>- is a useful feature, it can also easily eat up hard 

disk space if not detected or forgotten. / 
Quotas 

File systeni quot^ were introduced in NTFS 5. They allow the administrator of a computer that runs a version of Windows 
that suppom NTFS to set a threshold of disk space that useis may utUise. It also allows administrators to keep a track of 
how much disk space each user is using. An administrator may specify a certain level of disk space that a user may use 

take into account NTFS s transparent file-compression, should this be enabled. Applications that queiy the amount of fi-ee 

space will also see the amount of free space left to the user who has a quota applied to them. 
Sparse files ^ '^^ 

These are files which are mostly filled with zeros. This is called a sparee data set, and most things that generate such data 
sets are scientific applications, and they can generate very lai^e sparse data sets. Because of this, Microsoft has 
imp lemented support for sparse files by only allocating disk space for regions that do not contain blocks of zero data. An 
application that reads^a sparse file reads it in the normal manner with the file system calculating what data should be 
returned based upon the file offset. As for compressed files, the actual size of spai^e files are not taken into account when 
determining quota limits. ('>«P:'''en.wikipedia.org/wiki/NTFS#endnote_SparseFiles) 
Reparse points 

Introduced in NTFS 5.0. These are used by associating a reparse tag in the user space attribute of a file or directory. When 



the object manager (see executive) parses a file system name lookup and encounters a reparse attribute, it knows to reparse 
nnrinT^ 1°^"^' ''^'^'"^ '^^^^^^^^^^ ""eparse data to eveiy file system filter driver that is loaded into Windows 

2000. bach filter driver exammes the reparse data to see if it is associated with that i^parse point, and if that filter driver 
determines ^ match then it mtercepts the file system call and executes its special functionality. Reparse points are used to 
implement Volume Mount Points, Directory Junctions, Hierarchical Storage Management, Native Structured Storage and 
Smgle Instance Storage: o o & 

Volume mount points 

Similar to Unix mount points, where the root of another file system is attached to a directory. In NTFS, this allows 
additional file systems to be mounted without requiring a separate drive letter (like C: or D:) for each. 
Directory Junctions 

Similar to Volume Mount Points, but reference other directories in the file system instead of other volumes. For instance 
the directory C : \exampledir with a directory junction attribute that contains a link to D: \linkeddir will 
automatically refer to the directory D : \linkeddir when it is accessed by a user-mode application. They are the 
equivalent of a Unix symbolic link, though in Unix a symbolic link can be applied on files as well as on directories PI 

(http://en.w1k1ped1a.0rg/wikimTFS#endnote_RussinovichNTFSDirJunctions) 
Hard links 

Similar to directory junctions, but used for files instead of directories. Hard links can only be applied to files on the same 
voluine since an additional filename record is added to the file's MPT record. Short (8.3) filenames are also implemented as 
additional filename records that don't have separate directory entries. 
Hierarchical Storage Management (HSM) 

Hierarchical stor^e management is a means of transferring files that are not used for some period of time to less expensive 
storage media. When the file is next accessed the reparse point on that file detennines that it is needed and retrieves it fi-om 



Native Structured Storage (NSS) 

NSS was an ActiveX document storage technology that has since been discontinued by Microsoft. It allowed ActiveX 
documents to be stored m the same multi-stream fonnat that ActiveX uses intemally. An NSS file system filter was loaded 
and used to process the multiple streams transparently to the application, and when the file was transferred to a non-NTFS 
formatted disk volume it would also transfer the multiple streams into a single stream I''! 
(http;//en.wikipedia.org/wiki/NTFS#cndnote_SaviIleNSS) 

Volume Shadow Copy (VSS) 

Efficiently keeps historical versions of files and folders on NTFS volumes by copying old, newly-overwritten data to 
shadow copy (copy-on-write). The old file data is overlaid on the new when the user requests a revert to an earlier version. 
Un heavily loaded systems, Microsoft recommends setting up a shadow copy volume on separate disk to reduce the I/O 
load on the main volume. 

File compression 

NTFS can compress files using a variant of the LZ77 algorithm (also used in the popular ZIP file format), f^] 
(http://en.w1k1pedia.0rg/wikimTFS#endnote MSCompression) A u»,„„„u.„ J v \ j ^. ■ 

. - *^ ' Although read-wTite access to compressed files is transparent, 

Microsoft recommends avoiding compression on server systems and/or network shares holdmg roammg profiles because it 
puts a considerable load on the processor. f^J (http:/''en.wikipedia.org/wiki/NTFS#endnote_MSCarapressionRecommendations) 

Single Instance Storage (SIS) 

When there are several du-ectories that have different, but similar files, some of these files may have identical content, 
bingle instance storage allows identical files to be merged to one file and create references to that merged file. SIS consists 
of a file systena filter that manages copies, modification and merges to files; and a user space service (or groveler) that 
searches for files that are identical and need merging. SIS was mainly desiged for remote installation servers as these may 
have multiple installation images that contam many identical files; SIS allows these to be consolidated but, unlike for 
example hard Unks, each file remains distinct; changes to one copy of a file will leave others unaltered 
(http://en.wikipedia.org/wikimTFS#endnote_SISWin2kMSWhitePaper) 

Enciypting File System (EPS) 

Provides strong and user-transparent encryption of any file or folder on an NTFS volume. EFS works in conjunction with 
the EPS service, Microsoft's GiyptoAPI and the EFS File System Run-Time Library (FSRTL). As of February 2004, its 
encryption has not been compromised. 

EPS works by enciypting a file with a bulk symmetric key (also known as the Pile Encryption Key, or FEK), which is used 
because it takes a relatively smaller amount of time to encrypt and decrypt large amounts of data than if an asymmetric key 
cipher IS used. The symmetric key that is used to enciypt the file is then encrypted with a public key that is associated with 
ttie user who encrypted the file, and this encrypted data is stored in an alternate data stream of the encrypted file. To 
decrypt the file, the file system uses the private key of the user to decrypt the symmetric key that is stored in the file header. 
™, ^ ^1™^^^''^ to decrypt the file. Because this is done at the file system level, it is transparent to the user. 

[8] (http://en.w1k1ped1a.0rg/wiki/NTFS#cndnbte Win2kEFS) A ic« ;„^„„^«f„ 1 • . • . 

> Also, in case of a user losing access to their key, support for recovery 

agents that can unenciypt files has been built in to the EFS system. 



Symbolic links 

Introduced in Windows Vista onward, they are similar to Windows' shortcuts, but inside the NTFS' metadata. The new 
NTFS symbolic links work in a similar way to the symbolic links that have existed in Linux and similar operating systems 
smee the early days of Unix. 

Limitations 

The following are a few limitations of the NTFS file system. 
Reserved File Names 

Though the filesystem supports paths up to ca. 32,000 Unicode characters with each path component (directory or 
filename) up to 255 characters long, certain names are unusable, since NTFS stores its metadata in regular (albeit hidden 
and for the most part inaccessible) files; accordingly, user files cannot use these names. These files are all in the root 
directory of a volume (and are reserved only for that directory). The names are: $Mft, $MftMirr, SLogFile, $ Volume, 
$AttrDef, . (dot), $Bitmap, $Boot, $BadClus. $Secure, SUpcase. and $Extend PI 
(http://e„.wikipcdia.org/wikimTFS#e„dnote_Rese.^^^^^ ^^^^ ^ ^^^^^ ^^^^ ^ 

Maximum Volume Size 

In tiieory, the maximum NTFS volume size is 2^-1 clusters. However, the maximum NTFS volume size as implemented in 
Wmdows XP Professional is 232-1 clusters. For example, using 64 KiB clusters, the maximum NTFS volume size is 256 
TiB minus 64 KiB. Usmg the default cluster size of 4 KiB, the maximum NTFS volume size is 16 TiB minus 4 KiB. 
Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 TiB, you must use dynamic 
volumes to create NTFS volumes over 2 TiB. 

Maximum File Size 

Theory: 16 EiB minus 1 KiB {2^ bytes minus 1 KiB). Implementation: 16 TiB minus 64 KiB {2** bytes minus 64 KiB) 
Alternate Data Streams 

Care must be exercised when copying or moving files fi-om NTFS to other filesystem types. Windows system calls and 
programs can have varying behavior with regard to alternate data streams and might silently strip those which could not be 
stored on the destmation filesystem. A safe way of copying or moving files is to use the BackupRead and Backup Write 
system calls, which allow to enumerate streams, to verify whether each stream could be written to the destination volume 
and to knowmgly skip offending streams. 

Notes 

1. ^ "Paragon Software Group (http://www.paragon.ag/)" 

2. ^ "Sparse Files (http://msdn.microsoft.com/libraiy/default.asp?url=/library/en-us/fileio/fs/sparse files.asp)", MSDN 
Platform SDK: File Systems. KetrievedUay 22,2005. r _ r 

3. ^ Mark Russinovich, "Inside Win2K NTFS, Part 1 (http://msdn.microsoft.com/library/default.asp?url=/library/en- 
us/dnw2kmagOO/html/NTFSPart 1 .asp)" 

4. ^ John Saville, "What is Native Structured Storage? (http://www.windowsitpro.com/Article/ArticleID/13785/I3785.html)" 

5. File Compression and Decompression (http://msdn.microsofl.com/library/default.asp?iirl=/libraty/en- 
us/fileio/fs/file_compression_and_decompression.asp)". MSDN Platform SDK File Systems. Retrieved Aug 18, 2005. 

6. ^ "Best practices for NTFS compression in Windows (http://support.microsoft.com/defauIt.aspx?scid=kb;en- 
us;Q25 1 1 86). " Microsoft Knowledge Base. Retrieved Aug 1 8, 2005 . 

7. ^ "Single Instance Storage in Windows 2000 (http://research.microsofl.com/sn/Farsite/WSS2000.pdf)". Microsoft 
Research & Balder Technology Group, Inc. 

8. ^ ^How EFS Works (http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp? 
url-/resources/documentation/windows/2000/ser/er/reskit/en-us/distrib/dsck_efs_WQPT.asp)"McTO^o//»ri«i/ovi'5 2000 
Resource Kit 

9. "How NTFS Works (http://wvvw.microsofl.com/technet/prodtechnol/windowsserver2003/library/TechRef/8cc5891d- 
bf8e-4 1 64-862d-dac54 1 8c5948.mspx)" Windows Server 2003 Technical Reference 
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